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REMARKS 

Claims 1-5, 6-10 and 12 are pending. Claim 6 has been canceled. 

Claims 1 and 12 have been amended to incorporate the features of Claim 6 and 
that the look-up table comprises a list of identifiers that is searched by the identifier 
look-up element. These claims have been amended for clarity purposes only and no 
subject matter is being added. Basis for the amendments can be found in Claim 6 and 
at page 5, lines 16-21 of the description. 

On page 2 of the Office Action, Claims 1-10 and 12 are currently rejected under 
35 USC § 103(a) as being unpatentable over US 6,963,586 (hereinafter referred to as 
"Henriksson et al.") in view of US 6,515,993 (hereinafter referred to as "Williams et al."). 
Applicants are traversing this rejection. 

The application presently contains two independent claims, namely Claims 1 and 
12. Below, Applicants explain that Henriksson et al. in combination with Williams et al. 
do not teach all of the elements of Claims 1 and 12. 

As stated at Col. 1 , lines 7-12 of Henriksson et al., this document relates to a 
reception packet processor and a protocol processor. Henriksson et al. attempts to 
address a number of technical problems, but most notable is the technical problem of 
evolving protocols. Henriksson et al. therefore attempt to find a solution that will cope 
with evolving protocols. While Henriksson et al. is entitled "Method and Apparatus for 
General-Purpose Packet Reception Processing", the "general purpose" aspect of 
Henriksson et al. is nevertheless highly targeted to packet reception processes that 
accommodate the transmission of larger data volumes (for example, an ATM packet of 
more than 1500 bytes) that are transmitted as packets (column 6, lines 9-18). The 
packet reception process is also based upon the premise that the location, encoding 
and usage of header information and data fields are already defined within a standard. 

Henriksson et al. suggests a protocol processor that is based upon a general 
purpose microprocessor enhanced with special features specific to packet processing. 
Henriksson et al. teaches a protocol processor that processes first header information to 
provide instructions regarding processing of second header information (col. 3, line 15). 
Henriksson et al. also teaches provision of selected instructions for processing the 
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second header information (col. 3, lines 19-22) and generation of payload flags that are 
used by execution units (col. 3, lines 24-25). As such, it is clear that Henriksson et al. 
still relies upon the main processor for processing a payload (col. 5, lines 37 - 55). 

According to col. 3, lines 31-45, the protocol processor can extract one or 
multiple fields from the first header information, and compare the extracted field(s) 
against one item of predetermined data and process the extracted field(s) using an 
"arithmetic and logic unit". Subsequently, the protocol processor can extract a plurality 
of fields and compare the extracted fields with a plurality of parameters supplied by a 
second look-up table using a plurality of comparators (col. 3, 47-62). This comparison is 
achieved, however, using a single pattern that is either "built-in" or supplied by a 
"parameter code book" (col. 9, lines 21-31). Consequently, in order to compare multiple 
patterns, Henriksson et al. discloses the use of multiple comparators (col. 9, lines 50- 
52). Henriksson et al. is not capable to comparing the header information against an 
arbitrary number of identifiers where each identifier may have an arbitrary value. 

Furthermore, according to col. 7, lines 54-63, Henriksson et al. discloses the use 
of multiple look-up tables for holding instructions by dividing a program into separate 
parts; for the application stated, this approach seems beneficial. The look-up tables are 
not intended and not capable of holding matching identifiers. 

Williams et al. relates to a data communication networking device, in particular 
data network switches capable of communicating frames to both local area networks 
and virtual local area networks (col. 1, lines 8-11). More specifically, Williams et al. 
relates to a multi-port switch (col. 2, line 67). As described at col. 2, lines 53-59 and col. 
3, lines 1-10, Williams et al. concerns an internal rules checker and a port vector FIF 
logic operating together to process data frames based upon header information of the 
data frame to add, strip, or modify VLAN tags. The internal rules checker sends a 
forwarding descriptor, which contains information about the frame type and operation 
code information, to the port vector FIFO logic. The port vector FIFO logic then 
selectively manipulates the VLAN tags and instructs dequeuing logic in the output ports 
on a port-by-port basis on how to transfer the data frames. Williams et al. does not 
relate to automotive communications network. Indeed, VLANs do not exist in 
automobiles as such networks are not required. 
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Referring to Claim 1 , Claim 1 recites an automotive information controller for an 
automotive communication system having at least one communication bus having an 
information unit with an identifier portion and a data portion corresponding to said 
identifier portion, said information controller comprising: 

• an identifier look-up element for sending a predetermined program selector to a 
signal handler upon determination that the identifier portion of a received 
information unit corresponds to a predetermined identifier associated with the 
predetermined program selector; wherein 

• the program selector defines an operation to be performed on the data portion by 
the signal handler; and 

• said identifier look-up element further comprises a look-up table for storing a list 
of identifiers, 

• said identifier look-up table element searching the look-up table in order to find 
said predetermined identifier and said predetermined program selector 
corresponding to said identifier portion. 

However, and with particular reference to the underlined features of Claim 1 
above, the teachings of cited Henriksson et al. in combination with Williams et al. fail to 
teach the identifier look-up element comprising a look-up table for storing a list of 
identifiers , and the identifier look-up table element searching the look-up table in order 
to find the predetermined identifier and the predetermined program selector 
corresponding to the identifier portion, as recited in Claim 1 . Furthermore, the teachings 
of Henriksson et al. in combination with Williams et al. fail to teach an automotive 
information controller, as recited in Claim 1 . 

It is submitted that Henriksson et al. is incapable of searching a look-up table, 
because Henriksson et al. has a target of operating as described therein within a single 
clock cycle , i.e. insufficient time exists. 

Additionally, it is submitted that the skilled person would not contemplate 
referring to Henriksson et al. for the following reasons. The automotive information 
controller of Claim 1 is intended to relieve the main processor completely or as much as 
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possible of the workload to receive, process and send packets. This is necessary 
because, in an automotive communications network, target applications involved 
frequently send many relatively short messages (1-8 bytes) that have to be re-routed, 
merged with other messages and then sent. Use of an interrupt driven general purpose 
processor of the type disclosed in Henriksson et al. for such tasks will only serve to 
keep the processor very busy, and may result in lost data in cases of high workload. 
Consequently, the use of the processor of Henriksson et al. in an automotive context is 
a very inefficient usage of the processor. Furthermore, the above-mentioned risk of data 
loss would be unacceptable to the skilled person in an environment where safety- 
related data is communicated. In Henriksson et al., there is no significant need to relieve 
the main processor, because a much lower number of messages arrive per channel. 
The fact can be easily adduced by considering that the combined length of the header 
information in the Ethernet layer (14 bytes) and the header information in the IP layer 
(20 bytes), as indicated at col. 1 1 , lines 3-6, is much longer than the combined length of 
the identifier (1 1 or 29 bits) and the payload (1 - 8 bytes) of a CAN packet to be 
processed by the automotive information controller of Claim 1 . Thus, the solution 
proposed by Henriksson et al. teaches the skilled person to implement packet 
processing in a main processor, which for the above reasons is technically 
disadvantageous and incompatible with the objectives of the present invention. 

The utility value of the automotive information controller of Claim 1 is that it can 
support a typical customer application employing more than 500 identifiers, each 
associated with a different payload size, format and subsequent processing to maximize 
throughput. The number of identifiers is application dependent and the actual values are 
defined arbitrarily by customers. In contrast, the approach of Henriksson et al. is very 
different, but not unexpectedly since Henriksson et al. addresses a different problem 
space to that of the present invention. The purpose of the approach disclosed by 
Henriksson et al. is to support the processing of selection fields in a header, as defined 
by many communications standards in order to distinguish between different header 
formats. By way of example, consider the bit used by the CAN standard to distinguish 
between an 1 1-bit or 29-bit wide header. In contrast, the automotive information 
controller as recited in Claim 1 is based upon an assumption that such activity is 
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performed by a protocol receiver, because it is a protocol dependent feature and so 
should therefore be performed in such a unit. If this was not the case, it would not be 
possible for a single automotive communications controller of Claim 1 to receive 
messages in respect of different protocols, for example: CAN, LIN, UART, IIC. The 
automotive information controller operates at a different level of abstraction to the 
processor of Henriksson et al.; the automotive information controller simply receives an 
identifier or header information together with payload data for further processing. 
Hence, it can be seen that the automotive information controller of Claim 1 provides 
benefits in the context of automotive applications that Henriksson et al. is unable to 
deliver, either alone or in combination with Williams et al. 

Turning to the reasons advanced in the Office Action for combining the teachings 
of Henriksson et al. with Williams et al., it is submitted that the arguments proposed are 
circular and employ hindsight. In this respect, the only reason given in the Office Action 
to make the modification to make the receiving apparatus is. in fact, to make the 
claimed information controller . There is no teaching in the cited prior art suggesting the 
modification and the present application only teaches the modified apparatus. See 
MPEP Section 2141 : "The teaching or suggestion to make the claimed combination and 
the reasonable expectation of success must both be found in the prior art, and not 
based on applicant's disclosure!,] citing In re Vaeck."". Also, MPEP Section 2143.01 , 
Subsection IV entitled "Mere Statement That The Claimed Invention Is Within the 
Capabilities of One of Ordinary Skill in the Art is Not Sufficient By Itself To Establish 
Prima Facie Obviousness." applies. 

In addition, the reason provided: "to optimize packet processing?' , js 
conclusionarv. It does not set forth how the combination of the two references would 
obtain the stated benefit . "Rejections on obviousness cannot be sustained by mere 
conclusionary statements; instead, there must be some articulated reasoning with some 
rational underpinning to support the legal conclusion of obviousness." KSR, 550 U.S. at 

, 82 USPQ2d at 1396. In this respect, the statement provided {"to optimize packet 

processing") is indeed a conclusionarv statement and not articulated reasoning and so a 
sufficient reason has not been provided . See also Ex parte Penhasi, BPAI Appeal No. 
2007-2534 (December 13, 2007) ("The Examiner has not articulated a sufficient reason 
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why one skilled in the art would have modified [the art] and arrived at the presently 
claimed subject matter."). It is therefore submitted that the Office Action has not 
satisfied the necessary criteria of providing a reasoning to modify Henriksson et al. and 
so the rejection raised is improperly formulated. 

Furthermore, the skilled person would not contemplate combining the teachings 
of Henriksson et al. with Williams et al., because Henriksson et al. relates to ATM 
communications, whereas Williams et al. relates to VLANs and so are technically 
incompatible. 

In view of the reasoning provided above, Applicant submits that Henriksson et 
al. in view of Williams et al. does not render Claim 1 obvious. 

Claims 2 to 1 0 depend from Claim 1 . By virtue of this dependence, Claims 2 to 
10 are also not obvious. 

Claim 12 is a method claim corresponding to the apparatus of Claim 1 . 
Consequently, the arguments set forth above in support of Claim 1 apply equally to 
Claim 12. As such, it is therefore respectfully submitted that the teachings of Henriksson 
et al. in combination with Williams et al. fail to teach the identifier look-up element 
comprising a look-up table for storing a list of identifiers , and searching the look-up table 
in order to find the predetermined identifier and the predetermined program selector 
corresponding to the identifier portion., as recited in Claim 12. Furthermore, the 
teachings of Henriksson et al. in combination with Williams et al. fails to teach a method 
for using an automotive information controller for an automotive communication system, 
as recited in Claim 12. 

In view of the reasoning provided above, Applicant submits that Henriksson et al. 
in view of Williams et al. does not render Claim 1 2 obvious. 

The case is believed to be in condition for allowance and notice to such effect is 
respectfully requested. If there is any issue that may be resolved, the Examiner is 
respectfully requested to telephone the undersigned. 

If Applicant has overlooked any additional fees, or if any overpayment has been 
made, the Commissioner is hereby authorized to credit or debit Deposit Account 
503079, Freescale Semiconductor, Inc. 
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SEND CORRESPONDENCE TO: 

Freescale Semiconductor, Inc. 
Law Department 

Customer Number: 23125 



Respectfully submitted 




Davj6 GTEf&ezal 
Attorney of Record 
Reg. No.: 41,711 
Telephone: (512)996-6839 
Fax No.: (512) 996-6854 
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